This section is intended to introduce the reader to various aspects of the art that may be related to various aspects of the present invention. The following discussion is intended to provide information to facilitate a better understanding of the present invention. Accordingly, it should be understood that statements in the following discussion are to be read in this light, and not as admissions of prior art.
PCC Architecture in 3GPP
The architecture that supports Policy and Charging Control functionality is depicted in FIG. 1. FIG. 1 has been taken from TS 23.203 (V.9.5.0) that specifies the PCC functionality for Evolved 3GPP Packet Switched domain, including both 3GPP accesses (GERAN/UTRAN/E-UTRAN) and Non-3GPP accesses. The nodes that would receive any impact from this invention have diagonal lines.
The Policy Control and Charging Rules Function (PCRF) is a functional element that encompasses policy control decision and flow based charging control functionalities. The PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards a Policy Control and Charging Enforcement Function (PCEF). The PCRF receives session and media related information from an Application Function (AF) and informs the AF of traffic plane events. The PCRF shall provision Policy Control and Charging (PCC) rules to the PCEF via a so-called Gx reference point. The PCRF shall inform the PCEF through the use of PCC rules on the treatment of each service data flow that is under PCC control, in accordance with the PCRF policy decision(s).
The Application Function (AF) is an element offering applications in which service is delivered in a different layer (i.e. transport layer) from the one the service has been requested (i.e. signaling layer), the control of IP bearer resources according to what has been negotiated. One example of an AF is the Proxy Call Session Control Function (P-CSCF) of the IM CN subsystem. The AF shall communicate with the PCRF to transfer dynamic session information (i.e. description of the media to be delivered in the transport layer). This communication is performed using a so-called Rx interface.
The PCEF encompasses service data flow detection (based on filters definitions included in the PCC rules), as well as online and offline charging interactions (not described here) and policy enforcement. Since the PCEF is the one handling the bearers, the PCEF is where the QoS is being enforced for the bearer according to the QoS information coming from the PCRF. This functional entity, namely the PCEF, is located at the Gateway (e.g. GGSN in the GPRS case, and PDG in the WLAN case). For the cases where there is a Proxy Mobile IP (PMIP) instead of a GPRS Tunneling Protocol (GTP) between a Bearer Binding and Event Reporting Function (BBERF) and the PCEF, the bearer control is done in the BBERF instead. For the purpose of the present invention, the BBERF behaves as the PCEF.
When multiple addressable PCRFs have been deployed in a Diameter realm, an optional logical Diameter Routing Agent (DRA) function is enabled in the PCC architecture. This entity ensures that all Diameter sessions for Gx, Gxx, S9 and Rx interfaces, find the same PCRF. See FIG. 2.
PCRF Failover and Recovery Mechanisms in the Standards
The PCC architecture has been defined in 3GPP without considering the failover and recovery mechanisms of the involved entities. 3GPP specifies the failover and restoration mechanisms for most of the core network elements in 3GPP TS 23.007. Though PCC architecture has been so far out of the scope of this specification, there is some work in 3GPP to incorporate PCC in future versions.
On the other hand, 3GPP has analyzed different PCRF failover and recovery scenarios that are documented in 3GPP TR 29.816.
In a scenario where more than one PCRF exists in the PCC architecture, upon failure of a PCRF, an alternative PCRF is contacted. This solution assumes that no interaction exists amongst the more than one PCRF, and that a central entity (a so-called DRA) provides to any PCRF-client (namely PCEF or BBERF) information to select an active PCRF. In order to update the alternative PCRF, 3GPP proposes that each PCRF-client (PCEF, BBERF) stores the session data available before failing the formerly active PCRF, and updates the alternative PCRF with said session data. In a scenario where just one PCRF exists, or where no alternative PCRF exists to take the role and activities of the failing PCRF, 3GPP proposes that, upon recovery of the failing PCRF, each PCRF-client (PCEF) updates the recovering PCRF with session data previously saved. More specifically, the PCRF-client in this approach is aware of the PCRF failure and thus requests the DRA to provide information about other active PCRF.
However, 3GPP does not dictate the specific data and the frequency which the session data is saved for an eventual PCRF recovery procedure. Saving all session data at any time they are modified produces a significant work load for each PCRF-client, and the provision of the saved session data from each PCRF-client to the new active PCRF, or to the recovering PCRF, also produces a quite significant work load for the new active PCRF, or recovering PCRF, as well as for each PCRF-client.
PCC Failover Mechanisms in a Real Deployments
Some products (e.g. the Ericsson SAPC implementing the PCRF) are developing solutions based on the use of geographical redundancy. Some platforms allow that geographical redundancy at host level, i.e. there are two instances of the same PCRF, primary and stand-by. With this option, when the primary PCRF instance fails, the stand-by PCRF can take the control without involving the clients (e.g. PCEF). From the PCRF client perspective, there is a unique PCRF with a unique IP address and a unique Diameter Destination-Host.
Geographical Redundancy at host level is advantageous since                it is transparent to the clients (e.g. PCEF, BBERF or AF)        extra-signaling is avoided. No redirection mechanism has to be supported to find an alternative node        it is cheaper. High reliability is achieved without needs for a central entity such as the above DRA        
For these solutions based on conventional Geographical redundancy it is required that the primary PCRF instance and the stand by maintain the same replicated information. The standby instance requires having access to the same static information (configuration and provisioning information) than the primary one. Replication of dynamic information (session information) is also necessary if it is required that sessions on going are not affected when the stand by node takes the control upon a primary failover. However, solutions where the session information is replicated between the active and standby PCRF instances require that the active PCRF instance shall keep the stand-by PCRF instance updated in each session modification event, what may provoke high internal processing in the node, performance drop, system instability, and also requires a high capacity update link between PCRF instances.
For this reason conventional geographical redundancy solutions limit the replication to static information. With this approach at least it is ensured that the stand-by instance can take the control of all the new sessions being established, since it will have replicated all the non-volatile data (e.g. subscription data) in its internal (or external) data base. Since the volatile data is lost, ongoing sessions cannot be handled.
Problems with Existing Solutions
The alternatives proposed in 3GPP in TR 29.816 distinguish between deployments of multiple PCRF with DRA, and single PCRF. In a single PCRF deployment, the main drawback is that sessions cannot be maintained or can be maintained during a period of time but with the risk of obsolete information. In the solutions based on multiple PCRF, the PCRF client (e.g. PCEF, BBERF) shall detect the PCRF failure, and shall take actions to come through the situation detected. All the alternatives imply big impacts on the PCRF client, such as storing PCRF session data and updating procedures towards the active PCRFs.
On the other hand, as described in the previous clause, current deployments already offer some geographical redundancy solutions so that an alternative instance of the same PCRF node can take the control of the PCC interactions. As said before, those solutions would only work for the new sessions being established, since the PCRF has lost the dynamic data for the active sessions. In order for the PCRF to obtain the PCC rules applicable to a particular IP-CAN session, it needs specific access information, supported features, and subscription information.
The access information is conventionally obtained in the initial IP-CAN session establishment (i.e. in the first interaction that the PCEF has with the PCRF for a certain session, the client will provide all available access data), and, if the PCRF subscribed to changes over that information, in IP-CAN session modification operations received when a specific access data is modified (in this case, only the modified data may be received).
On the other hand, the features that both the PCEF and the PCRF supports are also negotiated during the first interaction and would apply during the whole IP-CAN session. The subscription information is obtained from an external or internal database.
With geographical redundancy in a unique logical entity, the PCEF will not be aware that the PCRF has failed, since a different PCRF has taken the control. Thus, when the PCEF has to contact the PCRF for a particular active IP-CAN session (e.g. some access data has changed), the PCEF will initiate an IP-CAN session modification towards the known PCRF. Since this message might only include data related to the specific change, the new PCRF would not have enough information to provide valid PCC rules.
One possible solution to this problem in the conventional approach can be based on a synchronization mechanism between PCRFs, i.e., the active PCRF shall keep the stand-by PCRF updated with the relevant session data. However, due to the nature of this node, the dynamic data can be changed very often, what would require high internal processing in the node.
FIG. 3 illustrates the described problem.
1. The UE initiates a PDN connection as per normal procedures
2. The PCEF initiates an IP-CAN Session Establishment towards the PCRF. It includes the identity of the subscriber, the features supported by the PCEF and the access data information available at the PCEF.
3. The request reaches the PCRF-FE that will address the request to the active PCRF (PCRF1).
4. The PCRF1 will make the policy decisions using the received access data and permanent subscriber data. The PCRF will derive the supported features using the feature information received in the request.
5. The PCRF1 provides the derived PCC rules, supported features and required events in the response.                NOTE: It is assumed that all the available access information is received in the request. According to the standard, it is also possible that, upon event-trigger subscription, if the PCEF has not included relevant information for the related subscribed events, it will send that information in a new request.        
6. PCRF-FE forwards the request to the PCEF
7. The PCEF responds back to the UE, following current procedures.
8. PCRF1 fails. PCRF-FE internally assigns a new PCRF (PCRF2) that can only take control of existing IP-CAN sessions.
9. The UE initiates a new interaction that requires PCC control (e.g. TFT change).                NOTE: The interaction can also be initiated by any other entity in the network (e.g. SGSN or HSS)        
10. The PCEF initiates an IP-CAN Session Modification towards the PCRF. It includes the IP-Address of the subscriber, the applicable event (e.g. TFT change) and the information related to that event (e.g. TFT filters).
11. The request reaches the PCRF-FE that will address the request to the new active PCRF (PCRF2).
12. The PCRF2 does not have dynamic information for this IP-CAN session, since all volatile data have been lost. Thus it is not aware of the PCC decisions made previously, nor the features that the PCEF supports. It does not know the access data relevant for the PCC Rules. Thus, either an error is generated, or incorrect PCC information will be provided.
Under this approach, dynamic data for any existing session are lost, and such existing sessions cannot be maintained.
Since the PCRF-client (PCEF, BBERF) is neither aware of the formerly active PCRF failure nor aware of the new active PCRF under this redundancy approach, if any modification of an already established IP-CAN session occurs, the PCRF-client simply submits those data related to the modification towards the new active PCRF, so that, even if the disclosure of 3GPP TR 29.816 v10.0.0 were to be considered, each PCRF-client cannot submit any previously saved session data simply because it is unaware of communicating with a new active PCRF.
In this situation, the new active PCRF knows neither decisions previously made by the formerly active PCRF, nor features supported by the PCEF, nor those access data required to provide PCC rules, because all these data had been received by the formerly active PCRF with the request for establishment of this IP-CAN session.
There is thus a need for an enhanced PCC architecture with an autonomous PCRF redundancy, that is, without participation of a central entity such as the above DRA, wherein a new active PCRF can obtain those dynamic data currently applying to existing IP-CAN sessions, which were received by the formerly active PCRF with the request for establishment of such IP-CAN sessions.